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ABSTRACT 


The distributed Agile development approach has been accepted by software 
companies due to its promised benefits. However, due to the controversial 
nature of distributed and Agile development, significant challenges arise 
from spatial, temporal, social, and cultural differences between distributed 
teams. Scrum, as the most popular Agile methodology, assumes that team 
members work together in the same room. But this principle does not apply 
in a realistic scenario where Scrum teams are distributed in different 
locations. Hence, proposing a risk management framework is necessary in 
order to succeed such teams. The purpose of this research was to propose 
a risk management framework in Scrum using the PRINCE2 methodology, 
which includes the perceived risks in distributed Scrum projects and their 


development causes and roots for managing these risks. By embedding distributed Scrum 
PRINCE2 in delivery layer of PRINCE2 and considering perceived risk factors, along 
Risk management with a hybrid model, a risk management framework was suggested. 
Scrum This framework has been used in a case study, and the results showed its 
proper functionality in detecting and eliminating potential risks in the case 
under study. Also, using this framework led to higher team efficiency in 
terms of increasing the number of completed user stories in each sprint. 
This is an open access article under the CC BY-SA license. 
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1. INTRODUCTION 

Risk management in software development as one of the pillars of software project management 
has always been a serious concern of researchers. Global experiences have shown that the success of these 
projects depends largely on proper planning and preparedness to reduce potential risks. This is mostly 
because software risk management involves approaches, processes, and tools that can reduce potential 
challenges in the management of risks [1]. This is important due to major changes in software development. 
Today, organizations use the hybrid approach including Agile software development (ASD) and distributed 
software development (DSD), which is called distributed Agile development (DAD), to develop 
better software products with better quality, time, and cost use. This approach helps to get the benefits 
of Agile and distributed development simultaneously. However, due to some inconsistencies, this approach 
is subject to significant challenges and risks, which will bring some kind of risk in software development [2]. 
Scrum, as an Agile popular methodology, is nowadays popular among many software teams in Agile 
distributed development. But the distribution of project stakeholders in the global software development 
(GSD) projects with the time period, geography, and culture often results in some of the challenges or risks 
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that may affect the processes of communication and collaboration that have been emphasized in 
this methodology [3]. 

Several studies have been conducted on risk management in Agile and DAD. Some of them merely 
point out the need to pay attention to risk management without specifying a particular agile method [4-6]. 
Others have focused on approaches and project management standards, such as PMBOK and PRINCE2, 
to provide risk management strategies for agile development in general or in a particular methodology [7-10]. 
Although the analysis of these studies shows that there are opportunities to provide more effective solutions 
in this field. In particular, the appropriate strategy and framework for efficient risk management in Scrum 
seems to be a serious necessity in DAD. 

By focusing on the mentioned challenge, this research has tried to provide a PRINCE2-based risk 
management framework in distributed Scrum and proves its effectiveness and operational effectiveness in 
practice. The rest of this paper is organized as follows; Section 2 introduces Scrum and distributed Scrum. 
Section 3 outlines the PRINCE2 methodology and then section 4 describes the related work. Section 5 
describes the research method adopted in this study, and then, in section 6, the proposed framework 
is introduced. Section 7 describes the results of using the framework in the case study, and finally, 
in section 8, conclusions and future work are expressed. 


2. SCRUM AND DISTRIBUTED SCRUM 

Scrum is an iterative and incremental framework for product management. In fact, it is a flexible 
and comprehensive development strategy in which the development team works as a unit to achieve 
a common goal, challenging the traditional approach for product development. It also enables the team to be 
organized through its daily communications. The different stages of Scrum are provided in Figure | [11]. 
Scrum, with a focus on project management in development, has only three roles in developing 
software products, including scrum master, product owner, and member of the development team [12]. 
Scrum, in theory, is recommended for small and medium-sized teams and small or medium-sized projects, 
but today it is used in large projects, multiple and non-integrated teams, and multi-site companies [13-16]. 
In 2013, the concept of LeSS for Scrum was introduced on a large scale with two basic frameworks [17]. 
The first framework, as shown in Figure 2, is suitable for a single project that has only one owner. 
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Figure 1. Scrum framework for Figure 2. Scrum in large scale 
software development (framework 1) [17] 


The second framework, as shown in Figure 3, is appropriate for a product that has more than 1,000 
people working on several different sites. In this framework, an important role, called area product owner 
(APO), has been added, whose special task is to prioritize and manage the site of the product backlog. 
Within this framework, the product backlog is divided into several regions. Each area includes a bunch of 
customer needs. Between 3 and 10 teams can operate in each area. Along with the benefits of DAD, 
there are many challenges [18], such as documentation, temporal, spatial, and cultural differences, 
team distributions, division and distribution of work, and so on, which are the most important factors in DAD. 
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3. PRINCE2 METHODOLOGY 

PRINCE2 is one of the most famous project management methodology used by individuals 
and organizations in various industries [19]. This method helps to successfully manage the projects, 
regardless of type or scale, through the requirements of the project. PRINCE2 is built on seven principles, 
backgrounds, and processes that can fit specific needs. A special version of PRINCE2, called Agile 
PRINCE2, has been presented in order to take advantage of PRINCE2 in Agile development, 
which is somehow the most sophisticated agile project management solution [20]. 
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Figure 3. Scrum in large scale (framework 2) [17] 


PRINCE2, as shown in Figure 4, consists of four integrated elements inducing principles, themes, 
processes, and project environment. There are seven principles that a project is not in compliance with 
PRINCE2 until they are all implemented [20]. The themes in PRINCE2 explain the aspects of project 
management that need to be addressed in parallel through the project. The themes can be seen in Figure 4. 
They explain the specific method used in PRINCE2 to manage projects [20]. Processes describe the project 
life cycle from initial idea to project closure as well as measuring the benefits. Each process provides 
lists of recommended activities, relevant responsibilities, and guidance on how to adapt to a specific 
environment [20]. The processes are starting up a project (SU), initiating a project (IP), directing a project 
(DP), controlling a stage (CS), managing a stage boundary (SB), managing product delivery (MP), 
and closing a project (CP). The risk management processes in PRINCE2 include five steps: Identify, assess, plan, 
implement, and communicate. 
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Figure 4. PRINCE2 methodology in project management 
A risk management framework for distributed scrum using PRINCE2 methodology (Mohammad Esteki) 
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4. RELATED WORKS 

Literature review shows a few risk management approaches in agile methods. In 2008, an integrated 
model of risk management and agile processes was proposed. The proposed model consists of three phases 
including product vision planning, product roadmap, and implementation, in which each phase has its 
specific risk management. Risk management includes risk identification processes, risk analysis, risk 
management planning, risk monitoring and control, end of risk and examination after the end of risk [21]. 
Failures in software projects have serious warning statistics and symptoms, one of which is the lack of risk 
management in the project management process. According to a report in 2016, during the period from 2004 to 
2012, more than 71% of projects were delivered after the due time, and more than 51% of the projects cost more 
than contracted [22]. 

In 2009, key challenges in the use of Scrum in distributed environments were identified, as well as 
the strategies that project managers used to overcome these challenges [23]. Finally, a conceptual framework 
for identifying and reducing risks in the Scrum-based GSD was presented. This framework includes a general 
overview of risks, current strategies, and approaches to reduce risks. Several case studies have been reported 
in this regard, but these studies are limited to one or more software companies. In 2010, by reviewing twelve 
case studies, thirteen DAD challenges were identified and classified into seven categories. These categories 
include culture, time zone, communication, trust, customer cooperation, training, and technology [24]. 

In 2015, a risk management model was proposed for Scrum using the PRINCE2 methodology [25]. 
The main reason for this combination, as the authors explained, is the process-oriented nature of both 
methods. That study showed that the most important feature of risk is its severity, and the most important 
place to talk about risk is Sprint planning. The results of that research show that the inclusion of Scrum in the 
PRINCE2 methodology leads to improved product delivery time [25]. In 2016, a rating method was proposed 
based on agile risk scoring to prioritize risk factors in Agile software development. To optimize risk factors, 
particle swarm optimization has been used as an iterative approach [26]. Organizations combine the DSD 
with Agile approach to achieve higher quality and, lower cost and time. In 2015, forty-five risk factors were 
identified in DAD projects and then categorized into five categories including lifecycle, collective awareness, 
project management, external stakeholder engagement, and technology launch [6]. In 2017, the same 
researchers developed their work and created a risk management framework for DAD projects. The 
framework has been implemented partially in three different companies, with satisfactory results showing 
that most of the risks have been defeated or their impact reduced [9]. 

In 2017, a study addressed forty solutions for risk management in Scrum projects based on experts’ 
opinions [27]. The four common practices of risk management in Scrum projects relate to aspects 
of communication, lessons learned, and individual behavior. On the other hand, the four less commonly used 
methods in Scrum refer to the main responsibility of the SM, the implementation of formal planning, 
and the use of risk management techniques and artifacts [27]. In 2017, in a research study, software agents 
were used to perform risk management tasks and collect data from the project environment for risk 
identification [28]. In this research, a risk management model was introduced in a risk management tool that 
uses software agents to manager the potential risks [28]. Also, another study aimed to define risk indicators 
and assess the probability of risk occurrence in Agile software projects in order to identify the potential 
risk factors [4]. 

In 2014, risk management researchers used the Scrum to reach the CMMI in the organization, 
which their proposed solution showing 71.94% of the success. They also predicted that their proposed 
solution would enable software companies to achieve a desirable CMMI and improve software products 
of high quality, and they concluded that by implementing risk management in the Scrum, the desired 
CMMI could be reached. This demonstrates the adaptability of the Scrum to the CMMI standard [29]. 
Some methodologies formally investigate risks and usually use some informal methods for risk 
management [30]. However, for software and IT professionals, software project failures are not uncommon. 
In fact, according to the Chaos report in 2009 from the standards group, only 32% of software projects 
were successful, which this issue has caused many challenges for industry and academic researchers in 
software projects to consider many risk factors. Software projects have been analyzed for many risk factors. 
In a study conducted in the China software industry, more than 31 risk factors have been analyzed 
in six dimensions [31]. 

The Scrum and PRINCE2 standards emphasize on risk identification in projects. In the traditional 
project management methods, less success is due to uncertainty issues. In uncertain environments, the Scrum 
approach can greatly help to identify risks rather than traditional ones. [32]. In another study, a combination 
model of DSDM and PRINCE2 was introduced, which issues related to development were handled by 
DSDM and management issues were carried out by PRINCE2. This study shows better project management 
dynamics and better control as well [33]. In a study, a five-step approach to agile risk management has been 
used, and a SWOT matrix has been used to analyze it [34]. To manage risk in software projects, the software 
team can use a combination of the same methods used for non-software projects. For example, PMBOK 
includes knowledge domains for the success of high-level projects that can be used independently of the type 
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of methodology [35]. In another study has proposed a Scrum-based risk management framework, called 
RBSM that combines risk management processes to improve the Scrum project issues [36]. 

One of the challenges of agile methods is the lack of regular planning. In a research study, a hybrid 
XP model and the PRINCE2 were introduced aimed at introducing a systematic, flexible, and agile project 
management method with agile characteristics [37]. The results indicated that using their proposed method, 
they presented a real quality software product with a lower cost and time in a real project. Table 1 shows 
a summary of the most important related studies. 


Table 1. Most important related works 


Study 
Nyfjord J. 2008 [21] 


Hossain E. 2009 [23] 


Kajko Mattsson 
2010 [24] 


Tomanek M. 
2015 [25] 


Agrawal R. 2016 [26] 


Shrivastava S. V. 
2015 [6] 


Shrivastava S. V. 
2017 [9] 


Tavares B. G. 
2017 [27] 
Odzaly E. E. 2017 [28] 


Rai A. K. 2017 [4] 
Mousaei M. 
Gandomani T. J. 
2018 [8] 


Achievement 

Proposing an integrated model with ASD 

And defining processes and roles for risk management 
Risk classification 

Addressing of existing strategies 

Providing a solution for risk reduction in Scrum 


Focus on classifying DAD issues 
Attention to various issues such as culture and trust 


Embedding risk management into Scrum 
Setting key risk identification meetings 
Determine the risk characteristics 
Prioritization of risks 


Identifying 45 risk factors 

Categorizing risk factors and providing the methods for 
managing them 

Risk classification 

Determine the importance of each area 

Examine the exact risk factors 

Focus on dealing with risks 

Provide 40 risk management strategies in Scrum 
Realistic model 

Support for risk management tools 

Estimation of risk occurrence 

Embedding risk management in Scrum 
Determining meetings to key risk identification 
Determining risk characteristics 

Officially risk documentation 


5. RESEARCH METHOD 
This paper explored how to use the PRINCE2 methodology to create a risk management framework. 
Then, the proposed framework was evaluated in a case study. 


5.1. Case study 


Limitations 
Not applicable in DAD 


The lack of importance of each class 

Not paying attention to cultural and 
managerial issues 

General classification 

The lack of importance of each class 

The overall classification and relevance of 
DAD 

Not applicable in DAD 


Lack of a systematic prioritization process 
Not applicable in DAD 
Lack of a systematic prioritization process 


Lack of details of the identification process 


Not paying attention to the source of 
the risks and identification process 
Lack of providing risk handling process 


Not applicable in DAD 
Not applicable in DAD 


The company under study was a software company working on core banking systems. In the case 
study, 3 teams were working in different sites. The delivery time of the product was estimated at 150 days 
and the duration of each Sprint was 2 weeks. The detail of the teams can be seen in Table 2. 


Table 2. The detail of the teams in the case study 


Team Size Average experience in Average experience Team location Description 
(number) software (years) in Agile (years) 
Team 1 8 5.5 2 Company headquarter - 
Team 2 5 5 2 Customer’s site/ Bank Product owner worked 2 days a week 
Team 3 6 5 2 Company 2™ building Product owner worked 2 days a week 


6. RISK MANAGEMENT FRAMEWORK 

The main idea behind the development of the proposed framework is the nature of PRINCE2 
and Scrum methodologies. PRINCE2 is the most commonly used project management method in the world 
and is increasingly used in conjunction with agile methodologies. Since many companies intend to use agile 
methods, preparing special guidance on employing PRINCE2 in an Agile environment is necessary, as shown 
in Figure 5 [38]. Initially, distributed Scrum was combined with PRINCE2 methodology. In other words, 
Scrum was used in the PRINCE2 delivery layer and a hybrid model was created. Reviewing the literature 
helped to collect and categorized the risks reported in Scrum projects, as shown in Table 3. Then, these risks 
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were placed next to the designed framework for ease of prediction. Figure 6 illustrates the risk management 
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framework in Scrum distributed using the PRINCE2 methodology. 
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Figure 5. Combining PRINCE2 methodology with agile methods [38] 


Risk factor 

Higher Interdependency 
Between the Teams (ISF) 
Team Recognizing in Every 
Sprint (ISF) 

Growth in Team Size or 
Development Site (ISF) 
Lower initial Velocity 
Difficult to Execute Fixed 
Price Projects 

Unavailability of Business 
Analyst (ISF) 

Lack of Uniformity in 
Multisite Team’s Capabilities 
(ISF) 

The Emergence of excessive 
Competition between Teams 
The Emergence of excessive 
Competition between Scrum 
Masters/Product Owners 
Ineffective Standup Meetings 


Difficulty in System Release 
Management and 
Development (ISF) 

Losing on Time on End-to- 
End Extensively 
Interdependent Transaction 
Rich Test Cycle across 
Distributed Teams 

Code Integration across 
Multiple Sites 
Requirements Conflicts 
amongst Multiple Product 
Owner 

Problem Related to the 
Priority of the Requirements 
Because of the Multiplicity of 
Product Owners 

Cross Functional Teams 
insufficient for testing of 
Large Projects 

Test data management 


Inadequate Prioritization of 
Requirements 

Area Requirements Mismatch 
with Feature Team 
Capabilities 

Requirements unclear to the 
Team 


Risk area 
Project Management 


Project Management 
Project Management 


Project Management 
Project Management 


Project Management 


Project Management 


Project Management 


Project Management 


Software Development 
Lifecycle 
Software Development 
Lifecycle 


Software Development 
Lifecycle 


Software Development 
Lifecycle 
Software Development 
Lifecycle 


Software Development 
Lifecycle 


Software Development 
Lifecycle 


Software Development 
Lifecycle 
Software Development 
Lifecycle 
Software Development 
Lifecycle 


Software Development 
Lifecycle 


Table 3. List of risk factors in distributed scrum 


Risk category 
Project Organization 


Project Organization 
Project Organization 


Project Planning and Control 
Project Initiation 


Acquisition and Development 
of Project Teams 
Acquisition and Development 
of Project Teams 
Acquisition and Development 
of Project Teams 
Acquisition and Development 
of Project Teams 


Standards of Agile Ceremonies 


Release Management 


Test and Integration 


Coding and Integration 


Requirement Elicitation 


Requirement Elicitation 


Test and Integration 


Test and Integration 


Requirement Analysis and 
Specification 
Requirement Analysis and 
Specification 


Requirement Elicitation 
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DSD property 
Spatial 

Distance 

Spatial Distance 
Spatial Distance 


Spatial Distance 
Spatial Distance 


Work/Development 
Culture 
Work/Development 
Culture 
Work/Development 
Culture 
Work/Development 
Culture 


Language Barrier 


Temporal Distance 


Temporal Distance 


Temporal Distance 


Large Project Scope 


Large Project Scope 


Large Project Scope 


Large Project Scope 
Large Project Scope 


Large Project Scope 


Spatial Distance 


Ref. 
[9] 


[9] 
[9] 


[9] 
[9] 


[9] 
[9] 


[39] 


[39] 


[9] 
[9] 


[9] 


[9] 
[9] 


[40] 


[9] 


[9] 
[9] 
[39] 


[9] 
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R# 
R21 


R23 


R24 


R25 


R26 


R27 


R28 


R29 


R30 


R31 


R32 


R33 
R34 


R35 


R36 


R37 


R38 


R39 


R40 


R41 


R42 


R43 


R44 


R45 
R46 


R47 


R48 


R49 


R50 


R51 


R52 


Table 3. 
Risk factor 
Inadequate Communication 
about End User Requirements 
Unavailability of Requirement 
Documents for Testing 
Poor Technical Debt 
Management 
Issues with Pair Programing 


Frequent Architectural 
Changes (ISF) 

Inconsistency in Design 
Standards of Distributed 
Teams (ISF) 

No Common Definition of 
Done 

Differences in Agile Practices 
and Standard of Processes 
followed by Multiple Teams 
Lack of Communication 
between Team and the Client 
Lack of Communication 
between the Team Members 
Under investment on Travel 
by the Management 

Lack of Documentation 
Lack of Face to Face 
Communication 

Poor Collaboration between 
Different Sites 

Issue of Coordinating the 
Members of Scrum Masters 
and Product Owners Team 
Lack of Trust between the 
Client and Offshore Teams 
(ISF) 

Lack of Trust between the 
Onshore and Offshore Teams 
(ISF) 

Lack of Collaboration 
between Developers and 
Quality Assurance Members 
Ineffective Scrum of Scrums 
Meetings 

Poor Coordination between 
Multiple Teams 
Unsuitability of Agile 
approach for Large 
Organization 

Delays and problems in group 
decision making 

The Complexity of 
Communication between 
teams Due to The 
Responsibility of Several 
Teams on the Area Product 
Owner 

Uncommon Language 

Lack of Communication 
Infrastructure (ISF) 
Inappropriate Tools Selection 
(ISF) 

Unavailability of Product 
Owner (ISF) 

Poor Coordination between 
Multiple Vendors 

Risk in Code Integration with 
Multiple Vendors 
Dependency on Third Party 


Inappropriate User Story 
Estimates with Multiple 
Vendors 


List of risk factors in distributed scrum (continue) 


Risk area 
Software Development 
Lifecycle 
Software Development 
Lifecycle 
Software Development 
Lifecycle 
Software Development 
Lifecycle 
Software Development 
Lifecycle 
Software Development 
Lifecycle 


Software Development 
Lifecycle 

Software Development 
Lifecycle 

Group Awareness 
Group Awareness 


Group Awareness 


Group Awareness 
Group Awareness 


Group Awareness 


Group Awareness 


Group Awareness 


Group Awareness 


Group Awareness 


Group Awareness 
Group Awareness 


Group Awareness 


Group Awareness 


Group Awareness 


Group Awareness 
Technology Setup 


Technology Setup 


External Stakeholder 
Collaboration 
External Stakeholder 
Collaboration 
External Stakeholder 
Collaboration 
External Stakeholder 
Collaboration 
External Stakeholder 
Collaboration 
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Risk category 
Requirement Elicitation 


Test and Integration 
Coding and Integration 
Coding and Integration 
Design 


Design 


Standards of Agile Ceremonies 


Standards of Agile Ceremonies 


Communication 
Communication 
Communication 


Communication 
Communication 


Coordination and Collaboration 


Coordination and Collaboration 


Trust 


Trust 


Coordination and Collaboration 


Coordination and Collaboration 
Coordination and Collaboration 


Communication 


Communication 


Communication 


Communication 
Infrastructure and Resources 


Tools Selection 

Customer Collaboration 
Multiple Vendor Involvement 
Multiple Vendor Involvement 
Multiple Vendor Involvement 


Multiple Vendor Involvement 
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DSD property 
Spatial Distance 


Spatial Distance 
Spatial Distance 
Spatial Distance 
Spatial Distance 


Work/Development 
Culture 


Work/Development 
Culture 
Work/Development 
Culture 

Spatial Distance 
Spatial Distance 


Spatial Distance 


Spatial Distance 
Spatial Distance 


Spatial Distance 
Spatial Distance 
Spatial Distance 
Spatial Distance 
Work/Development 
Culture 
Work/Development 
Culture 

Temporal Distance 


Large Project Scope 


Large Project Scope 


Large Project Scope 


Language Barrier 
Spatial Distance 


Work/Development 
Culture 

Spatial Distance 
Spatial Distance 
Spatial Distance 


Spatial Distance 


Work/Development 
Culture 
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Ref. 
[9] 


[9] 
[9] 
[9] 
[9] 
[9] 


[9] 
[9] 


[9] 
[9] 
[9] 


[9] 
[39] 


[9] 


[39] 


[9] 


[9] 


[9] 


[40] 
[9] 
[9] 


[39] 


[39] 


[9] 
[9] 


[9] 
[9] 
[9] 
[9] 
[9] 
[9] 
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Software 


Development 


Lifecycle 





Language Barrier 
8. Standards of Agile Ceremonies 
2. Ineffective Standup 
Meetings 


Temporal Distance 

2. Release Management 
1. Difficulty in System Release 
Management and 
Development {ISF} 

3. Testing and Integration 
1. Losing on Time on End-to- 
End Extensively 


Interdependent Transaction 
Rich Test Cycle across 
Distributed Teams 


4. Coding and Integration 


1. Code Integration across 
Multiple Sites 


Large Project Scope 

1. Requirement Elicitation 
2. Requirements Conflicts 
amongst Multiple Product 
Owner 
5. Problem Related to the 
Priority of the Requirements 
Because of the Multiplicity of 
Product Owners 

3. Testing and Integration 
3. Cross Functional Teams 
insufficient for testing of Large 
Projects 
4, Test data management 

6. Requirement Analysis and 

Specification 
1. Inadequate Prioritization of 
Requirements 
2. Area Requirements 
Mismatch with Feature Team 
Capabilities 


Spatial Distance 
1, Requirement Elicitation 
1, Requirements unclear to the 
Team 
3, Inadequate Communication 
about End User Requirements 
4, Unclear Objectives of 
Project 
3. Testing and Integration 
2. Unavailability of 
Requirement Documents for 
Testing 
4, Coding and Integration 
1. Poor Technical Debt 
Management 
3. Issues with Pair Programing 
5. Design 
1, Frequent Architectural 
Changes (ISF) 


Work/Development Culture 

5. Design 
2. Inconsistency in Design 
Standards of Distributed Teams 
(SF) 

7. Standard of Agile Ceremonies 
1, Differences in Agile Practices 
and Standard of Processes 
followed by Multiple Teams 
3. No Common Definition of 
Done 

































Work/Development Culture 
4. Acquisition and Development of Project Teams 
1. Unavailability of Business Analyst (ISF) 
2. Lack of Uniformity in Multisite Team’s A 
Capabilities (ISF) P HRs: 
3. The Emergence of excessive Competition 
between Teams 
4. The Emergence of excessive Competition 
between Scrum Masters/Product Owners 


Spatial Distance 
1. Project organization 
1. Higher Interdependency Between the Teams (ISF) 
2. Team Recognizing in Every Sprint (ISF) 
5. Growth in Team Size or Development Site (ISF) 
2. Project Planning and Control 
1. Lower initial Velocity 
3. Project Initiation 
1. Difficult to Execute Fixed Price Projects 
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Figure 6. Risk management framework in the distributed scrum 
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In the first step, the project mandate can identify the responsibilities of individuals, since one 
of the Scrum weaknesses is a strong dependence on the team members. In the case of leaving the team, 
it may cause the project to be stopped and broken. However, if defined in the project charter, it can greatly 
overcome this challenge with the project charter. The project board takes decisions to begin and enforces 
start-up permissions. The project manager starts the project by putting together the requirements and costs, 
and the project manager must work with the product owners to evaluate and clarify the project's 
requirements. When the project starts, the project manager will design steps and details. The project manager 
must connect the steps with Sprint, then the project enters the preparation phase. One of Scrum's weak points 
is that the area involved in the project is not yet measurable and cannot be estimated. By this preparation 
phase, the scope and extent of the project involved can be identified to a certain extent, which, by identifying 
the scope of the project, can be better off the probable risks of the project to determine. In border 
management, the risks are recorded and reported, and by the project management, the next steps 
are carried out. 

Each team has a Product Owner who is responsible for managing the requirements. The product 
owners and the development team discuss the product backlog and requirements that must be delivered to 
the next sprint. Scrum Masters must also design Sprints together with Project Managers and facilitate their 
implementation. Product backlogs are also prioritized by the PRODUCT OWNERS and are planned by 
the Scrum Master on the sprints of each team. The works are delivered to the development team as Sprint 
backlog, and development teams also publish a version of the product in time periods, which will be followed 
by the Sprint review meeting. Project Manager after the Sprint review meetings, must prepare a special report 
on the progress of the project and then submit it to the project board. The product owners and project 
manager are also explored through the burndown chart and weekly sprint meetings, which can partly identify 
and verify the project risks. 


7. RESULTS AND DISCUSSION 

The application of the framework in the case study was carried out by addressing 52 known risks in 
the literature review and their occurrence in practice. The results of applying it were analyzed by observing 
and collecting data in the range of | to 5 and analyzing them in three desirable categories including favorable 
(1 to 2.33), relatively favorable (2.34 to 3.66) and unfavorable (3.67 to 5). Figure 7 shows that out of the 75 
discovered risks, 42 risks (56%) have been eliminated. Of the 33 risks not eliminated 9 risks (12%) 
controlled, 8 risks (10.66%) mitigated, 3 risks (4%) aggravated and 13 risks (17.33%) only discovered. 
Figure 8 shows that 26 risks (50%) of 52 risks were discovered. Figure 9 shows that the factors of geographic 
distance and large project scope have led to a higher number of the probable risks, while different time offset 
and language have had the least effect on risk events in the studies. As shown in Figure 10, the risk areas 
of coordination and collaboration, communication, coding and integration, acquisition and development 
of project teams have been high-risk areas for DAD. Figure 11 also shows that group awareness, the software 
development lifecycle, and project management are the riskiest categories, the collaboration of external 
stakeholders, and the technology set up are the least risky ones. Figure 12 shows the discovered and 
eliminated risk in the case study. 

In order to ensure the effectiveness of the framework, in another part of the study, the framework 
was used to investigate and analyze the number of selected user stories in each Sprint and compare them with 
the completed ones. The results of using this framework in these two teams are shown in Figure 13. 
The statistics shown in Figure 13 show that during the project, the level of the finished or completed user 
stories gradually grew. In fact, applying the framework has helped the team to gradually increase its 
efficiency in completing and expanding more user stories. 





3 5 20 
20 42 È 
$15 z 10 
10 ; 
onl : 
0 s] 0 TE 
Mitigated Controlled Aggravated Only Discovered Eliminated Discovered 5 Not Discovered 
Risk factor impact Risk Status 
Figure 7. The impact of discovered risk factors Figure 8. The status of risk factors 


A risk management framework for distributed scrum using PRINCE2 methodology (Mohammad Esteki) 


1308 O ISSN: 2302-9285 


Coordination and Collaboration 


Coding and Integration 








Acquisition and Development of Project Team 

Line PrjectSope TT ipa 
Trust 

Requirement Elication 


Work/Development Culture Lid 


Project Organization 


DSD Property 


Risk Area 


Customer Collaboration 

Temporal Distance Sa Project Initiation 
Project Planning and Control 

Tool Selection 

Language Barrier ] Release Management 


Standards of Agile Ceremonies 


0 5 10 15 20 25 30 35 40 0 2 4 6 8 10 12 14 16 
No. ofrisk factors N. ofrisk factors 
Figure 9. The effect of DSD characteristics in Figure 10. Risk areas and their risk factors 


the occurrence of risk factors 


E 


Risk Category 


Extemal Stakeholder Collaboration go 





Technology Setup ] 


Sprints 


0 5 10 15 20 25 30 35 40 


No. of risk factors ee ee ee ee 


Figure 11. The number of risk factors in Figure 12. Discovered and eliminated risks 
risk categories 


1000 


950 en Aann  — 


900 


850 
800 


Story Point 


750 
700 
650 
600 
1 2 3 4 5 6 7 8 
=O==Selected| 950 930 960 930 980 950 940 950 
=== Done 770 780 810 800 850 840 830 840 


Sprint 


=@== Selected ==®=—=Done 


Figure 13. The number of user stories selected and done in the study 


8. CONCLUSION 

In this study, a risk management framework was developed by embedding Scrum in PRINCE2 
methodology and identifying risk factors along with five categories of software development including 
lifecycle, collective awareness, project management, external stakeholder collaboration, and the launch 
of the technology. The results of the framework implementation showed that the life cycle of software 
development, collective awareness, and project management were the most-risky categories of study. 
The success rate of the project, given the Story Points, is 85.89%, which is a desirable rate. Also, 78.66% 
of known risk factors (identification, evaluation, and control) were managed, which is significant. 
Given the definition of activity and roles, it was expected that Agile principles would decrease somewhat. 
However, according to the results, agile principles are relatively well preserved. 

Considering the scope of the proposed framework, it was expected that replacing it all at once would 
increase the risk in the project. The results show that the framework has been relatively favorable in this 
regard. Also, in terms of the impact of the framework on project costs, the performance is relatively 
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favorable. The results show that the framework has succeeded in filling the gap in the lack of a risk 
management method in Scrum. Also, the framework has worked well in terms of understanding and ease 
of learning and working in real environments. In terms of the flexibility of the framework in the operating 
environment and adaptation to team limits, there is also a relatively good performance. A significant number 
of risk factors are proposed by the framework. The results suggest that introducing these factors to the team 
will help to predict the challenges that may arise when implementing a Scrum project. 
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